問題解説: マルチホーム接続環境でのNAPT利用時における送出パケットの送信経路とISP側のパケットフィルタの関係についての考察
問題文
我社では、社内で上記のトポロジーでマルチホーム接続を実施している。
だが、通信状況が良くないと社員から苦情がきたため、回線断の状況などを調べる目的で、新しく通信監視のサービスを自社に導入することが決定し、監視サービス提供事業者に依頼した。
監視サービス提供事業者の仕様としては以下の通りである。
最初にテストの設定をしてもらったが、内部からの通信の疎通は問題なく出来るにもかかわらず、一部のIPでは疎通が取れずにアラートが上がりっぱなしになるという現象が発生した。
その原因を突き止めてほしい :pray: 。
当該ISPとの通信ではuRPFが設定されており、また両方で利用されているネットワーク帯は異なる。
当社に存在する ネットワーク帯 は以下の通りである。
このうち、192.168.2.128/30、192.168.2.132/30 はISPとの接続用でISPより提供されたIPであり、この組織が利用できるIP帯は 192.168.2.136/29 である。
ISP内ではISPではuRPF Loose modeと団体ごとの接続に利用しているBGPプロトコルでの経路フィルタが設定されている。
また、自社のコンピュータは192.168.2.0/25をNAPTを利用して接続している。
この問題では、当社が保有するCoreルータ以外の設定変更は不可能である。
また、広報する経路の設定は変更してはならない。
監視用サーバーはISP-A・ISP-B双方から疎通が可能であり、またISP・CORE間はBGPにて動的ルーティングが行われている。監視用サーバーのIPは現地店では開示されていない。
監視用サーバーの監視結果やその他必要な情報については問い合わせることで確認することが可能である。
注意
この問題は「外部から疎通ができない」というものであり、
内部からの疎通は全て成功する状態が正常である。
また、この問題のネットワークは他の問題のネットワーク、無線LANとの疎通性とインターネットへの対外疎通は存在しない。そのため、当問題のセグメント（192.168.2.0/24）以外には疎通不可能な状態が正常である。
制約
上流ルータ等、当該ルータ以外の設定変更はしてはならない。
BGPで広報する経路の設定は変更してはならない。
NATの変換IPを変更してはならない。
使用するネットワーク帯を変更してはならない。
クライアント側ネットワークを１つに集約してはならない。
この問題ではVRFを使用していないため、VRFを利用するネットワークを変更してはならない。
スタート
上記のように設定されたネットワーク帯とページ最上部に置かれたトポロジーで、インターフェイスにつけられたIPアドレスへの疎通が取れない
この設問では、サーバーはCore Loopbackに接続されているものとする
ゴール
Core Loopback、 ISP-A – Core、 ISP-B – Core のネットワークに所属していて実際にインターフェイスに割り当てがされている全てのIPとICMPによる疎通が外部から取れるようになる。
（Pingコマンドで疎通が確認できる）
情報
接続できるルータの情報は以下の通りである。
サブインターフェイスの数値に付与されているxはチームIDである。
例えばチームIDが30かつISP-A側インターフェイスの名前は GigabitEthernet 0.3010 となる。
トラブルの解説
この問題は、一部のインターネットサービスプロバイダー等で利用されるセキュリティ確保の方法の一つであるuRPF (Unicast Reverse Path Forwarding)に関する問題でした。
本来は自組織・相手組織を接続するネットワークは通信に使うためのものではないのですが、今回はそのIPに対して疎通確認を行なっており、どちらの回線が断絶したかを確認できるようにするという意図で問題が展開されていました。
uRPFとは
http://www.infraexpert.com/study/aclz22.html
このURLを見ていただくと理解ができるでしょう。
IPルーティングを行うルーターでは、パケット送出時にルーティングテーブルを確認します。
今回正常に接続ができていたLoopback IPへのパケットの送出手順は以下の通りとなります。
Coreルータのルーティングテーブル
ISP-Aルータのルーティングテーブル
ISP-Bルータのルーティングテーブル
上記の図では行きと帰りの経路が異なる様に記述していますが、今回の場合はどちらのISPからパケットが来ても、どちらのISPに返しても正常な動作です。
これは、この組織が割り当てを受けている/29のIPを双方のルータから経路広告しているため、また割り当てられているIPのため経路フィルタをされることなく当該IPに対するアクセスが全て許可されるためです。
今回正常に接続ができなかったISP側インターフェイスへのパケットフローは以下の通りとなります。
Coreルータのルーティングテーブル
ISP-Aルータのルーティングテーブル
ISP-Bルータのルーティングテーブル
当該ルータのルーティングテーブルをみて、デフォルトルートが向いている方のISPからISP-Coreのつなぎのインターフェイスには、発信パケットが同じISPを通るため正常にICMPパケットの返答が帰って来ます。
しかし、デフォルトルートが向いていない側のISPから着信した場合、そのパケットの送信元IPは通信が許可されていないが向いていない側のISPであるにもかかわらずデフォルトルートが向いている方のISPにパケットが送信されます。
CoreルータでICMPパケットが処理された後に、そのパケットの送出処理の際の出力インターフェイスはルーティングテーブルを参照した結果によるものであるからです。
今回は双方のISPで送信元IPがルーティングテーブルに乗っているかどうかを判断しパケットを送信するuRPFとBGPでの経路フィルタが設定されているため、デフォルトルートが向いていない側のISP側の送信元IPでデフォルトルートが向いている方のISPにパケットが送信された場合、ISP側ルータでパケットが破棄されます。
それにより、Ping疎通が不可能となっていました。
また、問題文として「経路フィルタを行なっている」ことから、CoreルータとISPを接続する線を経路広告しても疎通を取ることはできませんでした。
回答例
access-list 21 permit 192.168.2.128 0.0.0.3
access-list 22 permit 192.168.2.132 0.0.0.3
route-map REPLY-ISP permit 10
match ip address 21
set ip next-hop 192.168.2.129
route-map REPLY-ISP permit 20
match ip address 22
set ip next-hop 192.168.2.133
ip local policy route-map REPLY-ISPパケット送信元のIPをベースに、ネクストホップ（パケット送信先インターフェイス）を変更することでこのトラブルの回避が可能になります。
採点基準
パケットが本来出力されるべきインターフェイスから出力されていないことを指摘できる(10%)
ルーティングポリシーの設定を追加する(80%)
設定を保存する(10%)
講評
問題の点数が高かったことと、問題名から滲み出る頭おかしい臭、また出題形式の都合で前の問題でブロックされていたことにより出題時間が短かったことによって、解答もチェック依頼も0件でした。問題内容くらいはちょろっと見てくれてたら良いなあと思いつつ、この解説を読んで「あー！なるほど！」ってなってくれる人がいると良いなと思っています。
この問題を見て「😔」してた人もいたのかな、相当意地悪な作りにしたのは申し訳ない限りです。
今回の問題で出題したuRPFについては、BCP38(Best Current Practice 38)で提唱されている、ISPレベルでの不正な通信（送信元IPなりすまし）のブロックにも用いられる技術で、最近のISPでも採用例が増えてきている技術です。「繋ぐ」技術だけではなく「繋がせない」技術にも目を向けてもらえればいいなと思い出題しました。
何はともあれありがとうございました、次回も運営をしていれば、もっと簡単な問題で会いましょう。
(追加補足) バックボーンの裏話
実はuRPFなんて大層なことを言っていますが、今回の問題環境で行なっていることは「BGP経路フィルタ」・「ACLによるアクセス制御」のみでした。ルーティングテーブルを参照する方法がうまく行かなかったため、同じ制御が行われた想定で通信を制御していました。
また、ブラフとしてLANを2つ用意したり、敢えてルーティングにBGPを利用、NAPTの必須化などで「Configを読むだけでは何を聞きたいかわからなくする」様な戦略を取り、また疎通のチェックをチーム内で行うことはできなくする、ISP側設定は聞くことができない等で参加者のみなさま、また運営の祭典担当の方々に大変なお手間をおかけする様な問題にしました。